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Mapping Simple Network Management Protocol (SNMP) 
Notifications to SYSLOG Messages 
Abstract 


This memo defines a mapping from Simple Network Management Protocol 
(SNMP) notifications to SYSLOG messages. 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 


Copyright (c) 2009 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the BSD License. 
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SNMP and SYSLOG are two widely used protocols to communicate event 
ifications. Although co-existence of several management protocols 
one operational environment is possible, certain environments 


not 
in 


require that 


all event notifications be collected by a single system 


daemon, such as a SYSLOG collector or an SNMP notification receiver, 


via 
nec 
pro 


The 
str 


inf 
eve 


a single management protocol. In such environments, 


it is 


essary to translate event notifications between management 


tocols. 


latest version of SYSLOG, specified in [RFC5424], 


supports a 


uctured data element format. Structured data elements allow us to 
map between SNMP notifications and SYSLOG messages without losing 
ormation. In this memo, we specify a concrete mapping from SNMP 


nt notifications [RFC3416] into SYSLOG messages 


[RFC5424]. We 


specify how the SYSLOG message format should be utilized to carry the 


information contained in an SNMP notification message. 


str 
an 


sae ae 
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A new SYSLOG 


uctured data element is defined, which carries the PDU portion of 


SNMP notification message. 


Conventions 


ystem that has the capability of receiving SNMP notification 
sages from an SNMP notification originator and sending the SNMP 
a contained inside in a SYSLOG message format to a SYSLOG 
lector is referred to in this memo as an "SNMP-to-SYSLOG 
nslator". By definition, such a system should have an SNMP 
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notification receiver application and a SYSLOG originator running in 
order to be able to perform the functions of an "SNMP-to-SYSLOG 
translator". 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Background 
1. SNMP Notifications 


A detailed introduction to the SNMP Management Framework can be found 
in [RFC3410]. The SNMP Management Architecture is described in 
[RFC3411]. Managed objects are accessed via a virtual information 
store, termed the Management Information Base or MIB [RFC3418]. 
Objects in the MIB are defined using the mechanisms defined in the 
Structure of Management Information (SMI) [RFC2578]. 


An SNMP notification message is generated and transmitted by an SNMP 
entity on behalf of a notification originator application [RFC3413]. 
SNMP notifications are often used to notify a notification receiver 
application at a logically remote SNMP entity that an event has 
occurred or that a certain condition is present. There are two types 
of SNMP protocol operations that are associated with SNMP 
notification messages [RFC3416]: 


o SNMPv2-Trap-PDU, an unconfirmed notification delivery mechanism 
o InformRequest-PDU, a confirmed notification delivery mechanism 


The scopedPDU portion of an SNMPv3 trap or inform message has the 
following format [RFC3412]: 


ScopedPDU ::= SEQUENCE { 
contextEngineID OCTET STRING, 
contextName OCTET STRING, 
data ANY -- e.g., PDUs as defined in [RFC3416] 


} 


The data member of the SEQUENCE ScopedPDU carries an SNMPv2-Trap-PDU 
or an InformRequest-PDU. They both have the same structure: 
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PDUs ::= [7] IMPLICIT SEQUENCE { 
request-—id INTEGER, 
error-status INTEGER, —- ignored in notifications 
error-index INTEGER, -- ignored in notifications 
variable-bindings VarBindList 


} 
-- variable binding 


VarBind ::= SEQUENCE { 
name ObjectName, 


CHOICE { 
value ObjectSyntax, 
unSpecified NULL, -- in retrieval requests 
—- exceptions in responses 
noSuchObject [0] IMPLICIT NULL, 
noSuchInstance [1] IMPLICIT NULL, 
endOfMibView [2] IMPLICIT NULL 
} 
} 
-- variable-binding list 
VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind 


The first two variable bindings in the variable binding list of an 
SNMPv2-Trap-PDU or InformRequest-PDU are sysUpTime.0 [RFC3418] and 
snmpTrapOID.0 [RFC3418], respectively. If the OBJECTS clause is 
present in the invocation of the corresponding NOTIFICATION-TYPE 
macro, then each corresponding variable, as instantiated by this 
notification, is copied, in order, to the variable-bindings field. 

If any additional variables are being included (at the option of the 
generating SNMP entity), then each is copied to the variable-bindings 
field. 


In the case of SNMPv1 or SNMPv2c notifications, the contextEngineID 
and the contextName parameters are not present in notification 
messages. 


This document assumes that notifications are in the format defined in 


[RFC3416]. Notifications in the SNMPvl notification format MUST be 
translated as described in Section 3.1 of [RFC3584]. 
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2.2. SYSLOG Notifications 


The SYSLOG protocol is defined in [RFC5424]. The message contains a 


global header and a number of structured data elements. The ABNF 
[RFC5234] representation of a SYSLOG message is defined in RFC 5424 
[RFC5424]. The relevant productions for structured data elements 
are: 


STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT 


SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]" 

SD-PARAM = PARAM-NAME "=" $d34 PARAM-VALUE %d34 

SD-ID = SD-NAME 

PARAM-NAME, = SD-NAME 

PARAM-VALUE = UTF-8-STRING ; characters '’"’, ’\’ and 
7 ’]’ MUST be escaped. 

SD-NAME = 1*32PRINTUSASCII 


; except ’='’, SP, '’]’, %da34 (") 


UTF-8-STRING = *OCTET ; Any VALID UTF-8 String 
; “shortest form" MUST be used 


OCTET = $d00-255 
SP = $d32 
PRINTUSASCII = $d33-126 
NILVALUE = "o" 


3. Mapping SNMP Notifications to SYSLOG Messages 


In this section, we define how the scopedPDU portion from an SNMP 
notification message is used to generate a message in the SYSLOG 
format. The notification receiver application at the SNMP-to-SYSLOG 
translator is listening for incoming notifications. After a 
notification is received by the SNMP engine, the data portion is 
forwarded to the notification receiver application. The data portion 
contains the scopedPDU of the message, which is used by the SYSLOG 
originator on the SNMP-to-SYSLOG translator to generate a SYSLOG 
message and send it to a SYSLOG collector (or proxy). Note that 
every SNMP notification maps to exactly one SYSLOG message. 
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teretes + E e E + 

| snmp | snmp | | syslog +--------- + 
notification] notification tesa SSS nnan + message |syslog 
originator |\H-s-Sa-s-sasc > |syslog | |-------- >|collector 
+= + | [originator | | tasSsSss5= + 
$------------ + |  +------------ + | 

| snmp | snmp | +------------ + | syslog +--------- + 
|notification| notification | |snmp | message |syslog 
[originator  |------------- > notification | -------- >|collector | 
Toernee F receiver E SeSa= + 
+-----------—- + | +------------ + | 

| snmp | snmp | | 

|notification| notification | SNMP-to-SYSLOG | 

[originator |------------- >| translator | 

E + E E + 


Figure 1: SNMP-to-SYSLOG Translator Deployment 


A common deployment scenario is shown in Figure 1. There can be many 
SNMP notification originators that send SNMP event notifications to 
an SNMP-to-SYSLOG translator. The SNMP-to-SYSLOG translator extracts 
the data portion of the notification, generates a SYSLOG message, and 
sends the SYSLOG message to a SYSLOG collector, which is responsible 
for collecting and storing all notification messages. The arrows in 
Figure 1 indicate message flows, not individual messages. 


The SNMP-to-SYSLOG translator is not transparent for a SYSLOG 
collector. The global header of the SYSLOG message generated by the 
SNMP-to-SYSLOG translator is filled with parameters that are specific 
for the system running the SNMP-to-SYSLOG translator, such as its 
hostname, timestamp, etc. The data portion (scopedPDU for SNMPv3 or 
PDU for SNMPv1/SNMPv2c) of the SNMP notification message is contained 
in the structured data of the SYSLOG message. 


Implementations MUST drop invalid SNMP messages before they are 
passed to the SNMP-to-SYSLOG translator. 


3.1. SYSLOG Header 


The SNMP-to-SYSLOG translator fills the HEADER field of a SYSLOG 
message with parameters specific to the system on which it is 
running. The default facility level for SYSLOG messages containing 
SNMP notifications SHOULD be 3, which corresponds to messages 
generated by system daemons. The default severity level SHOULD be 5, 
which corresponds to "Notice: normal but significant condition". If 
the SNMP-to-SYSLOG translator has a notion of the type of 
notification that has been received, it might choose other values for 
facility and severity level. 
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The VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID, and MSGID fields 


in the SYSLOG message header are filled with values that are specific 
to the system on which the SNMP-to-SYSLOG translator is running. The 
character set used in the HEADER MUST be seven-bit ASCII in an eight- 


bit field, as described in [RFC5424]. 
3.2. Structured Data 


The STRUCTURED-DATA field of a SYSLOG message carries the ScopedPDU 


(or PDU) portion of an SNMP notification message. For the purpose of 
carrying SNMP notification data, a new SD-ID element is defined. The 


ABNF [RFC5234] representation of the new structured element is: 


SNMP-SD-ELEMENT = "[" SNMP-SD-ID [CTX] *VARBIND "]" 
SNMP-SD-ID = $x73.6E.6D.70 ; snmp 
CTX = CTXENGINE CTXNAME 
CTXENGINE = SP "ctxEngine=" %d34 HEXSTRING %d34 
CTXNAME = SP "ctxName=" %d34 PARAM-VALUE %d34 
VARBIND = SP VARNAME [SP VARLABEL] SP VARVALUE [SP VALSTRING] 
VARNAME = $d118 NUM "=" %$d34 OID %d34 ; “vN=" 
VARLABEL = %d108 NUM "=" %$d34 PARAM-VALUE %d34 ; "1N=" 
VARVALUE = VALOID / VALHEXSTRING / VALCOUNTER32 / VALCOUNTER64 
/ VALUNSIGNED32 / VALINTEGER32 / VALIP / VALNULL 
/ VALOPAQUE / VALTIMETICKS / VALSTRING 

VALOID = $d111 NUM "=" %d34 OID %d34 ; "oN=" 
VALHEXSTRING = $d120 NUM "=" %$d34 HEXSTRING %d34 ; “xN=" 
VALCOUNTER32 = $d99 NUM "=" %$d34 UNSIGNED32 %d34 7 “cN=" 
VALCOUNTER64 = $d67 NUM "=" %$d34 UNSIGNED64 %d34 ; “CN=" 
VALUNSIGNED32 = $d117 NUM "=" %d34 UNSIGNED32 %d34 ; “uN=" 
VALINTEGER32 = %d100 NUM "=" $d34 INTEGER32 %d34 ; “dN=" 
VALIP = %d105 NUM "=" %$d34 IPV4ADDRESS %$d34 ; "iN=" 
VALNULL = %$d110 NUM "=" $d34 %d34 ; “nN=" 
VALOPAQUE = $d112 NUM "=" %$d34 HEXSTRING %d34 ; “pN=" 
VALTIMETICKS = %$d116 NUM "=" %d34 UNSIGNED32 %d34 ; “tN=" 
VALSTRING = $d97 NUM "=" $d34 PARAM-VALUE %d34 ; "aN=" 
NUM = NONZERODIGIT O*DIGIT 
OID = OIDSTART *("." OIDSUBID) 
OIDSTART = (("0." / "1.") [%d49-51] DIGIT) / ("2." OIDSUBID) 
OIDSUBID = ZERO / (NONZERODIGIT *DIGIT) 
PARAM-VALUE = UTF-8-STRING ; characters '’"’, ’\’ and 

7 ’]’ MUST be escaped. 
UTF-8-STRING = *OCTET ; Any VALID UTF-8 String 


"shortest form" MUST be used 
HEXSTRING = *HEX 
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INTEGER32 = ["-"] NONZERODIGIT O*DIGIT 
UNSIGNED32 = NONZERODIGIT O*DIGIT 
UNSIGNED64 = NONZERODIGIT O*DIGIT 
IPV4ADDRESS = ds "." d8 "™." d8 "." d8 
d8 = DIGIT ; 0-9 
/ %d49-57 DIGIT ; 10-99 
fw 2DIGIT ; 100-199 
/ "2" %qd48-52 DIGIT ; 200-249 
/ "25" %d48-53 7 250-255 
HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f 
NONZERODIGIT = $d49-57 
ZERO = $d48 
DIGIT = ZERO / NONZERODIGIT 
SP = $d32 
Each SNMP-SD-ELEMENT starts with the SD-ID "snmp". The first two 
SD-ID parameters are "ctxEngine" and "ctxName". The context MUST be 


present in an SNMPv3 notification and therefore "ctxEngine" and 
"ctxName" MUST be present in a SYSLOG message generated by an SNMP- 
to-SYSLOG translator from an SNMPv3 notification. The 
contextEngineID is encoded as an hexadecimal string while the 
contextName is encoded as a UTF8 string. 


The remaining parameters in the "snmp" SD-ID correspond to the 
varbind list elements contained in the SNMP PDU. The name of a 
varbind is encoded as an OID in dotted notation. The rendered OID is 
carried in a "vN" parameter, where N identifies the position of the 
varbind in the varbind list of the SNMP message (the first varbind 
having the position 1). A MIB-aware implementation may in addition 
generate a parameter "IN" carrying the descriptor of the associated 
MIB object plus the instance identifier suffix (also called an OID 
label). The number N again identifies the position of the varbind in 
the varbind list of the SNMP message. 


The value of a varbind is encoded depending on its type according to 
the rules shown in Table 1, and type-specific parameter names are 
used to convey the type information. The number N again identifies 
the position of the varbind in the varbind list of the SNMP message. 
A MIB-aware implementation may in addition generate a parameter "aN" 
carrying an alternate textual representation of the value, which is 
obtained by applying DISPLAY-HINTs and translating named numbers into 
corresponding labels or OBJECT IDENTIFIER values to descriptors. For 
SNMP object types that have a DISPLAY-HINT of the form 'Ma’ or ‘Mt’, 
where M is some number, a MIB-aware implementation can choose to 
include the "aN" parameter and to suppress the corresponding "xN" 
parameter. This special case saves space for textual objects. A 
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receiver receiving an "aN" parameter without a matching value at 
position N can unambiguously convert the value carried in the "aN" 
parameter back to an OCTET STRING value. 


While the inclusion of additional parameters carrying OID labels or 
alternate value representations increases human readability, this 
comes at the cost of increased message size, which may cause 
truncation of SYSLOG messages. Therefore, implementations SHOULD 
provide a configuration mechanism to enable/disable the generation of 
parameters carrying OID labels or alternate value representations. 


$eSSSSenes asses ssese 4------------ aa bc iat eee cnn oe cacao marae + 

| SNMP Type | PARAM-NAME | Value Encoding 

+-------------------- 4------------ toa 55 S + 

| OBJECT IDENTIFIER | oN | dotted-decimal notation | 
OCTET STRING xN hexadecimal string 

| Counter32 cN unsigned decimal number 

| Counter64 | CN | unsigned decimal number | 

| Unsigned32 | uN | unsigned decimal number | 

| INTEGER, Integer32 | dN | signed decimal number | 

| IpAddress | iN | dotted quad notation 

| Opaque | pN | hexadecimal (BER) string | 
TimeTicks tN unsigned decimal number 

| NULL | nN | zero-length string | 

t-------------------- t------------ toa 5-5 E + 


Table 1: Mapping of SNMP Types to SD Params 


The SYSLOG message generated by the SNMP-to-SYSLOG translator may, in 
addition to the SNMP-SD-ELEMENT, include other structured data 
elements in its structured data part. These additional structured 
data elements MUST comply with the specification in [RFC5424]. 


In particular, the parameters in the "origin" SD-ID SHOULD identify 
the originator of the SNMP notification. A suitable value for the 
"ip" parameter MAY be taken from the snmpTrapAddress varbind if 
present, and a suitable value for the "enterpriseId" parameter MAY be 
extracted from the snmpTrapOID varbind. 


3.3. MSG Data 


The MSG part of the SYSLOG message is optional and may contain a 
free-form message that provides a textual description of the SNMP 
event notification. According to [RFC5424], the character set used 
in MSG SHOULD be Unicode, encoded using UTF-8 as specified in 
[RFC3629]. If the originator cannot encode the MSG in Unicode, it 
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MAY use any other encoding. The originator MAY use the "language" 
parameters defined in [RFC5424] to convey information about the 
natural language used inside MSG. 


4. Relationship to the SYSLOG-MSG-MIB 


A companion document [RFC5676] defines an SNMP MIB module to 
represent SYSLOG messages and to send SYSLOG messages as SNMP 
notifications to SNMP notification receivers. This section discusses 
the possibilities of using both specifications in combination. 


A SYSLOG collector implementing the SYSLOG-MSG-MIB module and the 
mapping of SNMP notifications to SYSLOG messages may be configured to 
translate received SYSLOG messages containing SNMP notifications back 
into the original SNMP notification. In this case, the relevant 
tables of the SYSLOG-MSG-MIB will not be populated for SYSLOG 
messages carrying SNMP notifications. This configuration allows 
operators to build a forwarding chain where SNMP notifications are 
"tunneled" through SYSLOG messages. Due to size restrictions of the 
SYSLOG transports and the more verbose textual encoding used by 
SYSLOG, there is a possibility that SNMP notification content will 
get truncated when tunneled through SYSLOG, and thus the resulting 
SNMP notification may be incomplete. 


An SNMP management application supporting the SYSLOG-MSG-MIB and the 
mapping of SNMP notifications to SYSLOG messages may process 
information from the SYSLOG-MSG-MIB in order to emit a SYSLOG message 
representing the SYSLOG message recorded in the SYSLOG-MSG-MIB 
module. This configuration allows operators to build a forwarding 
chain where SYSLOG messages are "tunneled" through SNMP messages. A 
notification receiver can determine whether a syslogMsgNotification 
contained all structured data element parameters of a SYSLOG message. 
In case parameters are missing, a forwarding application MUST 
retrieve the missing parameters from the SYSLOG-MSG-MIB. Regular 
polling of the SYSLOG-MSG-MIB can be used to take care of any lost 
SNMP notifications. 


5. Usage Example 
Here we provide an example of how an SNMP linkUp trap message is 
mapped into a SYSLOG message by using the mappings defined in 
Section 3.1 and Section 3.2. 
The linkUp notification is defined in [RFC2863] as follows: 
linkUp NOTIFICATION-TYPE 


OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } 
STATUS current 
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DESCRIPTION 
"A linkUp trap signifies that the SNMP entity, acting in an 
agent role, has detected that the ifOperStatus object for 
one of its communication links left the down state and 
transitioned into some other state (but not into the 
notPresent state). This other state is indicated by the 
included value of ifOperStatus." 

:= { snmpTraps 4 } 


The scopedPDU portion of an SNMP linkUp trap sent using the SNMPv3 
message format is shown below (the left column shows the Basic 
Encoding Rules (BER) encoding, while the right column indicates the 
corresponding ASN.1 definitions): 


30:2 7C SEQUENCE { 
04:08:80:00:02:B8:04:61:62:63 800002b804616263 
04:04:63:74:78:31 Totxi" 

A7:6A SNMPv2-Trap-PDU { 
02:03:6D:08:67 INTEGER 7145575 
02:01:00 INTEGER 0 
02:01:00 INTEGER 0 
30:5D SEQUENCE OF { 

30:0F SEQUENCE { 
06:08:2B:06:01:02:01:01:03:00 sysUpTime.0 
43:03:01:72:8C 94860 } 

30:17 SEQUENCE { 
06:0A:2B:06:01:06:03:01:01:04:01:00 snmpTrapOID.0 
06:09:2B:06:01:06:03:01:01:05:04 linkUp } 

30:0F SEQUENCE { 
06:0A:2B:06:01:02:01:02:02:01:01:03 ifIndex.3 
02:01:03 3h 

30:0F SEQUENCE { 
06:0A:2B:06:01:02:01:02:02:01:07:03 ifAdminStatus.3 
02:01:01 up(1) } 

30:0F SEQUENCE { 
06:0A:2B:06:01:02:01:02:02:01:08:03 ifOperStatus.3 
02:01:01 up(1) } } } } 

The corresponding SYSLOG message generated by the SNMP-to-SYSLOG 

translator is shown below. (SYSLOG examples should be considered to 

be on one line. They are wrapped on multiple lines in this document 


for readability purposes only.) 


<29>1 2003-10-11T22:14:15.003Z mymachine.example.com snmptrapd - ID47 
[snmp ctxEngine="800002b804616263" ctxName="ctx1" 
vl="1.3.6.1.2.1.1.3.0" 11="sysUpTime.0" d1="94860" 
v2="1.3.6.1.6.3.1.1.4.1.0" 12="snmpTrapOID.0" 
o2="1.3.6.1.6.3.1.1.5.4" a2="LinkUp" 
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v3="1.3.6.1.2.1.2.2.1.1.3" d3="3" 
v4="1.3.6.1.2.1.2.2.1.7.3" d4="1" a4="up" 
v5="1.3.6.1.2.1.2.2.1.8.3" d5="1" ad5="up"] 


The corresponding SYSLOG message has a priority value of 29, which 
means a facility level of 3 (system daemons) and a severity level of 
5 (Notice: normal but significant condition) according to the 
algorithm for calculation of priority value specified in Section 
6.2.1 of [RFC5424]. The rest of the fields in the header of the 
SYSLOG message are parameters that are specific to the system running 
the SNMP-to-SYSLOG translator. The SYSLOG version is 1 and the 
message was generated at 22:14:15.003Z on 2003-10-11T by the host 
"mymachine.example.com". The application on the SNMP-to-SYSLOG 
translator that generated the message was "snmptrapd"; there is no 
information about the process id, and the message on the SNMP-to- 
SYSLOG system is identified with the MSGID of ID47. 


The SYSLOG message contains one structured data element with an SD-ID 
of "snmp", which means that this is the scopedPDU portion of an SNMP 
event notification message. The data that is contained in the 
notification is associated with the ContextEngineID "123456" and 
ContextName "ctx1l". The request-id of the SNMP notification message 
was "7145575". Then follows the data portion of the scopedPDU. The 
first two variables contained in the data portion are always the 
sysUpTime.0 and snmpTrapOID.0. An snmpTrapOID.0O with a value of 
"1.3.6.1.6.3.1.1.5.4" means that this is a linkUp trap. The 
parameters v3="1.3.6.1.2.1.2.2.1.1.3" d3="3" mean that the SNMP 
notification message is carrying the ifIndex object, which has a type 
INTEGER and a value of 3. The parameters v4="1.3.6.1.2.1.2.2.1.7.3" 
d4="1" mean that the SNMP notification message is carrying the object 
ifAdminStatus, which has a type INTEGER and a value of 1. The 
parameters v5="1.3.6.1.2.1.2.2.1.8.3" d5="1" mean that the SNMP 
notification message is carrying the object ifOperStatus, which has a 
type INTEGER and a value of "1". 


6. IANA Considerations 


IANA registered the SD-ID value "snmp" together with the PARAM-NAME 
values specified in Section 3.2 in the registry for SYSLOG Structured 
Data ID Values according to Section 9 in [RFC5424]. The notation <N> 
indicates a position number. 


SD-ID PARAM-NAME 

snmp OPTIONAL 
ctxEngine OPTIONAL 
ctxName OPTIONAL 
v<N> OPTIONAL 
1<N> OPTIONAL 


Marinov & Schoenwaelder Standards Track [Page 12] 


RFC 5675 Mapping SNMP Notifications to SYSLOG October 2009 


Ta: 


9. 


9. 


o<N> OPTIONAL 
x<N> OPTIONAL 
c<N> OPTIONAL 
C<N> OPTIONAL 
u<N> OPTIONAL 
da<N> OPTIONAL 
i<N> OPTIONAL 
n<N> OPTIONAL 
p<N> OPTIONAL 
t<N> OPTIONAL 
a<N> OPTIONAL 


Security Considerations 


The security considerations discussed in [RFC5424] apply to this 
document. 


The SNMP architecture supports an access control mechanism, ensuring 
that SNMP notifications are only sent to receivers who are authorized 
to receive the notification. Network operators using this mapping of 
SNMP notifications to SYSLOG messages should enforce a consistent 
policy, preventing people from accessing SNMP notifications via the 
SYSLOG mapping that would otherwise not be accessible. 
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